Proposals for evolution of EAD

Comments below represent the opinion of the members of the Working Groups "EAD" and "EAC-CPF" of the French Association of Standardization as well as by archivists and librarians who use the formats. Consistency and interoperability between EAD and EAC-CPF have been taken into account.

These comments will be grouped into five sections:
- General comments
- Depreciating elements,
- Adding or making elements and attributes more consistent 
- Harmonization of EAD elements with EAC-CPF
- Links between EAD instances and other digital resources

1. General comments

-	We suggest changing the EAD into an XML schema, which is the reference version, but the starting point of this work should be the DTD EAD 2002, which is the conceptual model of the standard. The XML schema developed in 2007 is only a specific formalization of EAD.

-	We believe that requests for additions/corrections should be cautiously evaluated. Changes will not be required simply because of the difficulties of some users in EAD implementation. Practices or tools maybe inappropriate.

-	We suggest that the elements should be made more explicit and consistent with the current rules for writing XML schemas (for example, we could write <component> instead of <c>, <descriptionOfSubordinateComponents> instead of <dsc>, etc.).

-	We recommend using XML and Xlink libraries (see http://www.w3.org/XML/1998/namespace and http://www.w3.org/TR/xlink/). For example, the attributes @xml:id, @xml:lang and @xml:base should be included in EAD (these attributes are used in TEI), and the attribute @xml:id should be defined as an EAD attribute of type "id". The use of generic standardized elements and attributes provides interoperability.

-	The utility of a purely description-based <archdesc> merits further investigation. Should we maintain the essential text formatting elements such as <p>, <emph>, or linking elements within <archdesc>? Sometimes, a conceptual approach may be too restrictive…

-	In general, all the linking elements and attributes available in the EAD (<ref>, <archref>, <bibref>, <extref>, <ptr>, <extptr>, <dao>, <daogrp>, <arc>, etc..) do not work in the same way, and it makes them difficult to use. EAD should therefore move on to Xlink (use attributes @ xlink: href and @ xlink: type), but it is important to think in terms of type of object rather than in terms of links (the type of links is taken into account by Xlink).

-	The <bioghist> element does not belong semantically to EAD which focuses on the description of archival resources. It does however belong to EAC-CPF which provides a formal method for recording the description of records creators. Is the <bioghist> element useful when it is used as a substitute for the EAC-CPF format? However, <bioghist> may sometimes explain changes in the structure of an organization. Moreover, <bioghist> may highlight biographical or historical information in order to clarify the structure and the composition of a fonds, while a separate EAC-CPF authority record is more neutral and generic. We suggest that <bioghist> should not be removed from EAD, but the potential uses of this element should be explained and clarified. Here are some examples of use of the <bioghist> element in order to give some complementary contextual information within a EAD document:

<bioghist>
<p>Extrait de la circulaire préfectorale n° 13501/AC2 du 29 août 1941 adressée aux maires et administrateurs de commune mixte :
<blockquote>
<p>[...] Les opérations de recensement seront ouvertes le 1er septembre et closes le 10 septembre 1941. Vous aurez à prendre d'urgence un arrêté astreignant tous les juifs de votre circonscription à se rendre à la mairie qui leur délivrera les imprimés réglementaires de déclaration à remplir par les intéressés [...]</p>
</blockquote>
</p>
</bioghist>	

<c level="otherlevel" otherlevel="sous-dossier">
<did>
<unitid type="cote d'archives">FR ANOM 93/1H73/2</unitid>
<unittitle>Pesticides</unittitle>
<unitdate>1917/1918</unitdate>
</did>
<bioghist>
<p>Les pesticides sont utilisés dans l'agriculture pour protéger les plantes contre les maladies parasitaires. Anticryptogamiques ou fongicides, en usage au XIXème siècle et au début du XXème siècle, ils étaient des produits relativement simples et d’obtention aisée : cuivre sous forme de sels tels que sulfate, acétate, soufre, chaux, etc. On les employait par pulvérisations de bouillies ou poudrages sur les organes aériens des végétaux.
Pour encourager la production agricole, l'administration était chargée du ravitaillement de la colonie, de l'achat des produits à l'étranger jusqu'à la vente aux agriculteurs.</p>
</bioghist>
<scopecontent>
<p>Soufre et sulfate de cuivre, approvisionnement, enquête sur les besoins, répartition : circulaire, correspondance, déclaration, état récapitulatif des demandes, rapports.</p>
</scopecontent>
</c>	

-	EAD elements should be aligned with EAC-CPF elements. If two elements are almost the same (for instance <dateRange>, <dateSet> and <date> in EAC-CPF, and <unitdate> and <date> in EAD), but the EAC element structure is better, then we should use the same name in EAD. EAD elements about control description should also be changed, a <control> element should be provided just as a <control> element has been provided in EAC-CPF. In general, the ways for managing EAD documents need to be improved, especially in the case of retrospective conversion projects. See Section 4, below, for further explanation about alignment between EAD and EAC-CPF elements.

-	Concerning textual elements and the logical structure of these elements, it would be preferable to have the possibility to use TEI elements or elements of another related schema designed for this purpose. In general, it would be desirable to make EAD interoperable with EAC-CPF and other related metadata schemas.

-	We have received the following comments criticisms about EAD incompatibility with more generic metadata models:

-	“EAD is a model enabling us to create a type of structured documents while EAC-CPF schema has been designed as a structured set of metadata”;
-	“many things are implicit in EAD such as non-redundancy of information from high levels to the lowest levels in multi-level description”. 

We take issue with these comments for the following reasons:
-	EAD has been designed as a hierarchical format while EAC-CPF authority records are non-hierarchical, and it is also possible to extract non-hierarchical metadata from EAD structured documents.
-	Therefore, the number of Dublin Core that can be created depends on the <c> components contained in an EAD document. Through the @encodinganalog attribute, EAD elements can be matched to Dublin Core elements, and Dublin Core is a model that can be expressed in RDF.
-	Perhaps the possibility of extraction of Dublin Core metadata is not explained enough in EAD Tag Library.

-	Finally, it is essential that tools for converting DTD valid instances into schema valid instances be provided.

2. Depreciating elements

-	The DTD EAD Group and its elements <eadgrp>, Archival Description Group <archdescgrp> and Description of Subordinate Components Group <dscgrp> should be depreciated. These elements are not used. EAD implementers do not aggregate different EAD documents. EAD linking elements such as <extref>, <archref>, etc., enable users to establish logical links between different electronic documents (see for instance the “IREL” application of the National Archives of Overseas <http://www.archivesnationales.culture.gouv.fr/caom/fr/index_irel.html> , or the guide of records on slavery and slave trade <http://www.archives-esclavage.culture.gouv.fr/>).

-	We compared practices in the national archives and territorial archives as well in libraries. We propose to depreciate other elements, that are not used in France:
-	numbered components <c01> <c02>, etc.. (these elements are not implemented in the Archivists'Toolkit software);
-	linking elements should be reviewed with the implementation of Xlink (eg, <arc>, which should be removed);
-	<descgrp>: we propose that embedding plural elements be used as in the EAC-CPF schema;
-	table elements <table> <tgroup>, <thead>, <tbody>, <colspec>, <row>;
-	the <head> element is depreciated in the future information system of the National Archives. Territorial archives and the National Library use it because of limitations of EAD and tools. For instance, they use it because of the lack of attributes specifying the language and the script code of the information included in an element). Before depreciating <head>, we should therefore consider the reasons for its use.

3. Adding or making elements and attributes more consistent 

-	The <eadid> element is mandatory but it may have no content and no attribute whereas the @identifier attribute is not mandatory. This is not logical.

-	<titlestmt> element (in <filedesc> element):
-	it would be helpful to include several <author> elements within <titlestmt> element. Currently, we have to record the names of all the authors of a finding aid in a single <author> element, or we have to use a <titlepage> element (which may contain several <author> elements) in order to isolate each author name. It may become problematic when we want to extract Dublin Core metadata or to build a basic bibliographic record for the finding aid.

-	There is no specific element for the date on which the finding aid has been compiled: it would be useful in retrospective conversion projects if we could mention the first date of publication of a paper-based finding aid which is retroconverted in its original form (in <editionstmt> and <publicationstmt> elements; in <creation> element, etc.). Generally, EAD implementers should have the possibility to improve the management of EAD documents (a <control> element should be provided as a <control> element has been provided in EAC-CPF).

-	The <address> element should be structured as it is in the TEI schema. We think the <addressline> element is of extremely limited value. We propose that a typing attribute be made available as it was done for EAC-CPF.

-	<blockquote> element:
-	the attribute @type should be available within the <blockquote> element; it would enable us to specify the nature of a citation;
-	it would be helpful to make the <blockquote> element more semantic and to make it available in the <unittitle> element (for instance, the National Library of France uses incipit within <blockquote> as access points).

-	<title> element :
-	an attribute @certainty would enable us to distinguish between the title given by the author, the usual title of a work or of a document, and the title given by the person who arranged or described the documents but which does not correspond to the content (see, for example, some drawings of Victor Hugo);
-	it would be useful to add an attribute @resp like in TEI to indicate the responsibility of the creator of the title (this comment also applies to <unittitle>).

-	Elements <corpname>, <geogname>, <persname>, <famname>, <name>, <title>, <unittitle>:

-	Attributes to specify the language should be made available within these elements (see comment about @xml:lang attribute) as well as script code attributes, in order to manage parallel forms (see for example the description of documents in Arabic, Chinese or Hebrew).

-	The addition of these attributes would solve the problems about bilingual finding aids. The EAD Tag Library deals with this problem, but it is not possible to specify the language used within an element: <langusage> within <eadheader> serves to indicate the language(s) of the finding aid, but this information can only be provided once, unlike <langmaterial> which may appear in all the <did> elements. An attribute such as @xml:lang would serve to encode the language of each <scopecontent>, <note> or <unitid>, etc., so that we could build a visualization tool enabling the user to click on a button "French" or "English" to display the descriptions in the required language. Currently, we must record the descriptions in both languages in the same tag and it’s unnecessarily time consuming.

-	Certain elements containing directly text such as <physdesc> or <origination> need <p> elements rather than </lb> elements to do a line break.

-	The <physfacet> element needs an attribute @authfilenumber, because the @source attribute is already available in this element.

-	The <archref> element: a <scopecontent> sub-element would enable us to describe correctly related or separated archival material (all the sub-elements of <did> element are available within <archref>, but there are very few other elements; <scopecontent> is not available, so that we have to use <note> or <unittitle>).

-	The <acqinfo> element may be contained within <custodhist>. However, because <custodhist> serves to encode information about the chain of ownership of the materials being described, before they reached the immediate source of acquisition, it would be better if <acqinfo> was not embedded within <custodhist>.

-	The <descrules> element is a sub-element of <profiledesc>. However, <descrules> is only about the rules, standards, conventions, and protocols used in preparing the description, it does not bundle information about the creation of the encoded version of the finding aid. Is <descrules> to be included within <profiledesc>? The role of <descrules> and of <processinfo> should be clarified.

-	The <processinfo> element: the use of this element <processinfo> is not clear. Is it equivalent to the 3.7.1. element of ISAD(G) (explaining how and by whom the description is established) or is its use broader, as suggested in the Tag Library (to provide “information about accessioning, arranging, describing, preserving, storing, or otherwise preparing the described materials for research use”)? See also general comment about the <control> element of EAC-CPF and the management of EAD documents.

-	We propose that the elements <dao> and <daogrp> be made available within <altformavail>; this may be useful when copies of the materials being described are digital, such as reproductions used for the communication of documents.

-	The <daodesc> element is to be enhanced in order to provide documentary information on digital documents. The <daodesc> element only contains formatting elements (<p>, <list>, <note>, etc…). We suggest that <daodesc> contains more semantic elements in order to differentiate between born-digital and digitized documents, to record technical metadata (filename, version, format, size, volume, number of records, fixed / variable records, life cycle of the document such as its conversion or its migration into another format), to establish links to structured databases, or to specify the number of files if you create a link to a group of files via <daogrp>. We also suggest that <daodesc> includes the elements <accessrestrict> and <userestrict> concerning the digital document itself (the access and use rights of the digital document may differ from those of the original).

-	EAD can not handle the exclusion of initial articles of titles. For instance, a title such as “Le Rouge et le noir” is ordered with the letter “R” and not with the letter “L”. It seems there is no solution:
o	NORMAL="Rouge et le noir": the index is not understandable
o	NORMAL="Rouge et le noir (Le)": problems may occur with the alphabetical order
o	NORMAL="Le Rouge et le noir": it is contrary to cataloging practices.

4. Harmonization of EAD elements with EAC-CPF

-	The EAD elements <abbr>, <abstract>, <address> and <addressline> are not used in France, but they were maintained in the EAC-CPF schema; <addressline> should be made more consistent with EAC-CPF (see Section 3).

-	The <chronlist> element is maintained in the EAC-CPF element <biogHist>, as well as <event> and <chronItem>; although these elements will not be used in the information system of the National Archives, it seems desitable to keep them in EAD for providing consistency with EAC-CPF; generally speaking, the elements embedded within the EAD element <bioghist> (<address>, <bioghist>, <blockquote>, <chronlist>, <dao>, <daogrp>, <head>, <list>, <note>, <p>, <table>) should be reviewed in comparison with the EAC-CPF element <biogHist>.

-	The EAD element <date> is not the same as the EAC-CPF element <date>; one should differentiate between the dates of the described documents (contained in <unitdate>) and the other significant dates mentioned in other elements than <unittitle> or <scopecontent>; in addition, the "bulk" value of the attribute @type is useful for archival institutions (it enables to mention predominant/bulk dates within a wide date range) and the notion of “predominant/bulk dates” should be kept.

-	The element <language> of the EAD element <eadheader> should be made consistent with the element <language> of the EAC-CPF element <languageDeclaration>.

-	Other necessary alignments: EAD <legalstatus> and EAC-CPF <legalStatus>, EAD <geogname> and EAC-CPF <place>, EAD attribute @source and EAC-CPF attribute @vocabularySource, EAD <emph> and EAC-CPF @style.

-	The <list> element was maintained in EAC-CPF.

-	The EAD element <persname> contains both the family name and the first name, whereas sub-elements <part> are used in the EAC-CPF <nameEntry> element. The solution implemented in EAC-CPF seems to be the best and the most generic, since it applies both to the names of individuals and of corporate bodies. It also makes it possible to isolate qualifiers associated with the name in an entry (for example, location qualifier associated with the name of a corporate body). In addition, it is compatible with the structure adopted by other metadata schemes like MADS (for authority records) and MODS (for resource description) - which is good for interoperability.

-	The EAC-CPF attribute @translitteration is an addition in comparison with EAD.

-	The EAD attribute @level aims to qualify the levels of description, whereas the EAC-CPF element <level> is a formatting element.

-	The inclusion of other XML instances should be made possible in EAD documents through <objectXMLWrap> and <alternativeSet> elements.

5. Links between EAD documents and other digital resources

-	It is possible to establish different types of links between EAD documents and other digital resources:
-	link between two EAD documents;
-	link between one EAD document and one (or many) EAC-CPF documents;
-	link between one EAD document and archival digital objects (JPEG image files, MP 3 audio files, MPEG video or audio files);
-	link between one EAD document and other resources providing additional information or illustrating the finding aid (URLs, XML, PDF, JPEG, MP 3, MPEG files, other formats).

-	The linkage mechanisms will depend on the relationships users want to establish. For instance, if you consider linkage mechanisms between EAD et EAC-CPF, links from an EAD document are made through the @authfilenumber attribute of the <persname>, <corpname> and <famname> elements (the value of this attribute is only the identifier of the EAC-CPF document), with an attribute @role which enables users to type relationships and which is a CDATA attribute. It means that the value of this attribute may contain any set of character (“creator”, “author”, “collector”, “editor”, “holder”, etc).

-	Links from an EAC-CPF instance are established through the attribute @ xlink:href of the element <resourceRelation>. However, the @resourceRelationType which enables users to type relationships can only be qualified by three values (creatorOf, subjectOf and other). It would be preferable to open the list of values to be given to the attribute @resourceRelationType, and to make the use of @role (EAD) and of @resourceRelationType (EAC-CPF) more consistent.

-	Finally, it is possible to link an EAD document to an EAC-CPF document through the identifier of the authority record. However, a permanent link pointing to the authority record would be far more efficient (see general comment about Xlink).

-	Note: it is essential that users be allowed to use only EAD, available tools do not necessarily implement both EAD and EAC-CPF.